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Rempr^s 

The Examiner rejected claims 1 to 33 under 35 U.S.C. 102(e) for 
purportedly being anticipated by United States Patent No. 6,092,1 1 4 to Shaffer et 
a). CShaffeO- 

Applicant refers the Examiner to the Background of the Invention, page 2, where 
Applicant has defined the problem in the state of the art as: 

"there remains a need for an electronic data communication system for 
message transmission to wiretess communications devices which 
recognizes the computational power and bandwidth limitations 
associated with these devices, the varied computational and display 
capabilities of these devices, the variety of available electronic message 
formats, and the costs associated with ownership and operation of these 
devices,*, emphasis added. 

Applicant describes and claims the conversion of message attachments to 
address the limited data resolution capabilities {e.g. processing and/or display 
and/or audio) of the communication devices. Applicant provides amended claim 
1 below as an illustrative example of claim amendments for the purpose of 
addressing the Examiner's objections, also discussed below. In particular, 
Applicant notes in the claims that that the data size contained in the attachment 
document as received is greater that the data size of the converted data sent to 
the network terminal, as matched to the data resolution capabilities of the 
network device, which te contrary to the operation described for prior art 
message/attachment conversion systems. 

Claim 1 - An electronic data transmission server comprising; a data 
receiver for receiving a request for transmission of an incoming message 
including an attachment document to a network terminal over a 
communications network, the attachment document including content for 
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presentation on the network terminal and presentation data defining the 
presentation of the content on the network terminal; a data processing 
system in communication with the data receiver for converting the 
attachment document in accordance with the at feast one data filtration 

parameter tp frffwmmo<tote rtMa resoWn capabilities of frs network 

terminal , the data processing system being configured to perform the 
conversion by retyping fr? timber pf bytes QCQypftd fry the 
presentation data to provide converted data incfudlng the content and the 
reduced presentation data; and a data transmitter in communication with 
the data processing system for transmitting an outgoing message 
containing the converted data to the network terminal over the 
communications network. 

Support for the amendments to independent claims 1, 10, 19, and 23 can 
be found at page 11, lines 13-25, page 12, lines 5-10 and 25-34, page 16, lines 
14-20, and page 18, lines 5-10. 

Examiner Cited Art 

Shaffer 

Applicant notes Examiner's citation of Shaffer, column 1 , lines 47-50, which 
describes the MIME conversion, as a basis for the 35 U.S.C. 102(e) rejection, 
Applicant is confused by the Examiner's reasoning for relying upon this passage 
to support the rejection, as MIME is simply a conversion of binary 8 bit data, to 7- 
bit ASCII characters for message transmission purposes. Applicant strongly 
believes that MIME conversion to ASCII characters does not result in displavable 
text (or other presentable information) for use by the user of the network terminal 
for interaction with the attachment, e.g. reading and understanding the text (e.g. 
content) of the attachment as intended by the original attachment sender. 
Instead, Applicant submits that ASCII conversion results in an unintelligible string 
of characters (not "text"), used for encoding readable text for message 
transmission purposes only. This string of unintelligible characters is then 
subsequently decoded at the target destination, once received, in order to 
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provide the original unchanged message text, which is contrary to the invention 
as claimed. Applicant invites the Examiner to provide a proper example where 
message text Is first encoded using MIME techniques for subsequent display and 
interpretation (not decoded) by the intended receipient of the message text. 
Applicant provides a simple definition obtained via the Internet from the 
University of Maryland, Office of Information Technology, which supports 
Applicant's view of MIME as a messaging protocol, nothing more; 

" Today's computer technology thinks in 8-bit bytes. When 
information is transmitted these days, its usually done so in an 8- 
bit fashion. However, there are instances when a transport 
medium will only handle 7-bfts. Furthermore, when it comes to E- 
Mail, there must be some consideration for systems that are 
based upon IBM's EBCDIC (Extended Binary Coded-Decimal 
Interchange Code), rather than the ASCII (American Standard 
Code for Information interchange) code that we are most familiar 
with. MIME makes sure that messages meet these criteria! \ 

Accordingly, Applicant submits that the Examiner has incorrectly interpreted 
MIME as conversion from a formatted Word Processing document to a text 
document, which Applicant points out that MIME is in fact a conversion to data 
packets tor transmission, nothing more. 

Further, Applicant submits that Shaffer in column 1 discusses the use of MIME 
or other available protocols for "accomplishing the encoding" in order "to 
accommodate transmission wtthin a network" of file attachments. Applicant 
submits that Shaffer discusses the use of these encoding protocols to convert 
attached file (of email messages) to text, for facilitating sending of the converted 
text within the message over the network. Further, Shaffer notes The converted 
text is then reconverted to its original form at the receiving client device", 
emphasis added (see column 1, lines 49-51). Further, Applicant notes at column 
1, fines 52-54 that Shaffer notes "At the recefving client device, the same 
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encoding standard must be used to decode the attached file, if the file is to be 
accessed", emphasis added. 

Accordingly, Applicant submits that Shaffer's discussion of MIME encoding does 
not address the features of the invention as currently claimed, as the encoding 
techniques are designed for encoding undifferentiated streams of data, 
regardless of their context, in order to restore the lull data stream at the receiving 
end, rather than accommodating the data resolution capabilities of the network 
terminal (as presently claimed). 

Further, Applicant submits that Shaffer describes a method and system for 
exchanging electronic messages, such as email messages, that Include isolating 
personal computers and other client devices from the process of converting a 
message attachment from one file format to a second file format In Shaffer's 
disclosure, file-format conversions are out-tasked to enhance file accessibility, 
tree computer resources, and conserve a user's time. In particular, Shaffer 
describes that the access requirements of each attachment (to electronic 
messages) are compared to the application capabilities of a target client device 
(data resolution of the attachment itself is ignored). H it is determined that a file- 
format conversion is required, the conversion operation is assigned to a server 
that supports the process of reformatting the attachments for subsequent access 
by the application resident on the target client device. Shaffer notes in column 
7 t lines 12,13, 'The file format conversion at step 52 is executed using known 
techniques. Conventionally, computer software is utilized to change an 
attachment from one file format to another". 

Applicant would like to bring to the Examiner's attention that Shaffer further 
states Thus, if a file attachment is received that requires an application that is 
"foreign 11 to the receiving computing device, the first Issue fs whether the 
computing device is capable of converting the attachment to an accessible file 
fonmaf . Applicant submits that this should be interpreted to mean that Shaffer 
places emphasis on the ability of the target client device to open the message 
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attachment, rather than emphasizing changes to the contents of the attachment 
to address the data resolution capabilities of the network terminal. 

Applicant further notes that Shaffer states in column 1 , lines 55-64 that "Even if 
the attached file is property decoded at the receiving client device, the file will not 
be accessible unless the client device has the required application program for 
opening the attached file. Typically, an attachment has a file format that is 
specific to an application . For example, an email attachment of a word 
processing text file may be specific to a particular word processing program. 
Access to the text is possfirfe only if the receiving client device includes the 
program or has the capability of converting the decoded file to another file format 
that is accessible", emphasis added. Applicant submits that this should be 
interpreted to mean that Shaffer places emphasis on the ability of the target client 
device to open the message attachment, rather than emphasizing changes to the 
contents of the attachment to addres s the data resolution capabilities of the 
network terminal. 

In conclusion on Shaffer, Applicant submits that the correct interpretation of 
Shaffer Is for a simple conversion process, from one format to another. The 
location is actually given a vague treatment, as client, server and second server 
are all mentioned as possibilities, with the second server being the preferred 
embodiment. The fact is that the size of the converted object is never considered. 
There is also no consideration of the capabilities of the target device for any data 
size limitations. Accordingly in view of the above discussion, Applicant believes 
that Shaffer Is silent as to changing the contents of the attachment document to 
addres s the data resolution capabilities of the network terminal . Instead, Shaffer 
only discusses the conversion and transmission of the entire content of the 
attachment, except in a differing format 

On other pertinent Shaffer issues for dependent claims, the Examiner cited 
column 3, lines 1-20 against Claim 30. Applicant would like to point out to the 
Examiner that one example for the registry referred to in Claim 30 is a Resource 
Registry for Identifying printing devices on the Internet, not a PC Application 
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Registry on the client computer as described by Shaffer This difference Is 
further proof that the teachings of Shaffer should be interpreted as application- 
centric rather than device-centric. 

Further, on page 3 of the Office Action, the Examiner comments on dependent 
claims 5,14 and 22, and cites that Shaffer in column 1, line 22 should be 
interpreted as indicating that including graphics as an attachment is not 
innovative. Applicant strongly believes, in view of the above presented 
discussion, that doing a MIME conversion of graphics to plain characters will not 
reduce the byte fength of the graphics once displayed, nor wilf the resolution of 
the graphics be modified as a result of the MIME conversion. Again, Applicant 
invites the Examiner to provide proper examples to the Applicant that 
demonstrate the principle of data size reduction and/or graphics resolution 
reduction (for message attachments) as a result of MIME conversion. In 
particular, Applicant reminds the Examiner that any provided data size / graphics 
resolution reduction benefits of MIME converted data need to be presentable on 
the network terminal, as claimed. 

Accordingly, in view of the above presented arguments and claim 
amendments, Applicant considers the rejection of claims 1-33 under 35 U.S.C. 
102(e) as overcome. 

Eoaleston 

Applicant presents the following as a summary of past consideration given 
to Eggleston in view of currently amended claims 1 -33. 

Applicant submits that Eggleston describes a system for allowing wireless 
clients to control the amount and type of message data received from a remote 
server. As shown in Figure 2, the Eggleston system includes one or more 
wireless clients, a communication server, and one or more host servers in 
communication wrth the communication server. The communication server 
includes a profile database of filter parameters for each client (such as Message 
Priority, Date Sent, Message Size, Author and Subject - see Figure 5). The 
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profile database also includes granularity filters which specify whether the 
message should be truncated after "X" bytes, and whether an attachment should 
be removed from an e-mail message. Upon receipt of a data request from a 
wireless client, the communication server queries the host computer for the 
requested data. Using the client's profile data, the requested message Is "pre- 
stage" filtered (either by the host computer or the communication server) before 
the message is transmitted to the wireless client. 

Further, Applicant submits Eggleston does not disclose a data transmission 
server which is configured to reduce bandwidth requirements by converting 
content of an attachment to the message, and then transmitting the converted 
attachment mending the content and a reduced byte size of the associated 
presentation data. The converted attachment data can be sent as an outbound 
message or as a converted attachment associated with the outbound message. 

On the contrary, Applicant submits that Eggleston only discloses the granularity 
filters to effect the pre-stage filtering of e-mail messages . The disclosed 
granularity filters are "file attachment , "truncaBonT, and "header information? . 
The iile attachment" granularity filter provides the mobile client with one of two 
options: (1) it allows the entire e-mail attachment to be transmitted to the client, 
or (2) it prevents the e-mail attachment from being transmitted to the client. The 
"truncation" granularity filter only transmits the first X bytes of the e-mail message 
integrum. The "header information" granularity filter only extracts header 
information from the e-mail message. 

Further, Applicant notes that neither the "truncation 0 nor "header information" 
granularity filters of Eggleston process e-mail attachments at all. Any 
construction of Eggleston to include such features should be considered as 
impermissible hindsight in view of Applicant's specification. Applicant submits 
that by Eggleston including "file attachment* as an available granularity filter 
(when discussing separate "truncation 0 and "header information" granularity 
filters at column 8, line 31 through column 9, line 2), Eggleston demonstrates 
that the 'truncation 9 and "header information 1 * granularity filters only process e- 
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mail message bodies, not e-mail attachments. To conclude otherwise would 
render the "file attachment 1 filter redundant. Applicant submits Eggleston 
included the 'file attachment" filter as a required mechanism for removing e-mail 
attachments from their respective e-mail messages, and the "truncation" and 
"header information" granularity filters are intended for processing e-mail 
message text only. 

Accordingly, Applicant believes Eggleston does not teach or even suggest 
reducing network bandwidth usage by differentiating in a message the content of 
an attachment document from its presentation data, and then forwarding the 
content and amended presentation data to the recipient as converted 
data/document, as now recited in independent claims 1 , 10, 19, and 23. 

Conclusion 

In light of the above remarks and the amendments submitted herewith, the 
Applicant submits that independent claims 1, 10, 19, and 23 are novel over the 
cited references to date, taken either alone or in combination. As the remaining 
claims are dependent on, and narrower than, independent claims 1, 10, 19, and 
23 the Applicant submits that these claims are similarly novel over the cited 
reference. 

it is believed that the above remarks and amendments submitted herein 
have placed this present application in condition for allowance, and a Notice 
thereof is requested. If the Examiner has further concerns, he is encouraged to 
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contact Applicant's undersigned agent at (416) 862-4318. All correspondence 
should continue to be directed to listed address shown below. 



Registration No. 53,902 

Gowfing Lalleur Henderson LLP 

Suite 1600, 1 Fust Canadian Race, 100 King Street West 

Toronto, Ontario 

Canada M5X1G5 

(416)862-7525 
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